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1. Introduction 



For the operator of the machines and systems that are becoming more and more complex, achieving an efficient 
operation (techn. availability, output, . . .) is of decisive importance. Strategies for this are required which permit 
quick and effective intervention in case of malfunction. 
Here special importance must be attached to system diagnosis. 

In the scope of a prototype study a demonstrator for model-based diagnosis (MBD) was developed. For this, 
diagnostic methods that were developed at ZT SE4 were drawn upon. By means of these methods a real machine 
component was modeled and objects of diagnostic realized based on it. 

It was the goal of the investigation to demonstrate the technical feasibility of the approach and to find out what 
potential platforms can be drawn on for the use of this technology. A significant component was to highlight the fact 
that the user does not have to program the model-based diagnosis but rather interconnects the necessary modules 
with the process via the signals to be measured. 



2. Demonstration example 



The example chosen for this object is a section of a production line. It is the catch cup component of a screw station 
at AT ER. This component has the object of traversing a mechanism by means of pneumatic drives from a base 
position into an operating position and back. 



Cylinder 



Mechanism 



Base position 



Operating position 



4/2-way valve 



Magnetic valve 



[see source for diagram layout] 



Positioning signal 



Control 



Figure 1 : Pneumatic drive 



The catch cup is a safety device in automatic screwing. It consists of two pneumatic drives according to figure 1. 
Such a pneumatic drive is actuated via the magnetic valve. The directional valve engages and lets the compressed air 
flow into the left chamber of the cylinder, which thereupon traverses into position. 



3. Control modules 



Components of this type are customarily coordinated by process controls. In the example, simple control modules 
were programmed. These were interconnected to a process environment so that the diagnostic modules can be linked 
and tested. 



4. Model-based diagnosis 



Model-based diagnosis provides technologies that perform a continuous theoretical-actual comparison of the 
machine process and here calculate the probabilities of faults of the components integrated in the model. For this, 
explicit process models were used that contain a description of the behavior of the process. 
The process modules consist of modules that are in turn typed. An actual system is described by instances of these 
types. Thus it is possible, for example, to introduce the sensor component since the sensor for registering the base 
position and that for registering the operating position behave in the same manner. 

In the following, the example (from figure 1) is represented as a block diagram. There the components have already 
been marked with the possible faults. 
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Figure 2: Block diagram of the example 

For each component a fault model must be stored that describes the connection between the input and output 
quantities: gs ^ 



[see source for diagram layout] 

ga_sensor_defect 



Sensor 
(base position) 



i 



gs_sensor 

The sensor sends in faultless operation (-gs_sensor_defect) a 1 (gs_sensor) if the mechanism is in the base position 
(gs): 

gs & -gs sensor defect => gs_sensor. 

If the mechanism is outside of the base position (-gs) or if a sensor defect occurs (gs_sensor_defect), a 0 is sent 
(*gs_sensor). 



-gs 



=> - 



gs_sensor. 



gs sensor defect — > gs sensor. 

The output of the sensor is available as a niinimum value. 

measurablesignals [gs_sensor]. 

With the achieved granularity of the model there is a sufficiently precise process model to be able to make 
diagnostic statements up to the component level (cylinder, sensor, . . .). The modeling technology used offers the 
capability of realizing different degrees of freedom. The models have an interface via which the actor and sensor 
signals are registered. 

5. Diagnostic modules 

From the configured process model an executable diagnosis program (implemented in C++ or SCL) is generated 
automatically. 

The diagnosis program takes over the diagnosis-side progression through the theoretical process steps and the 
calculation of the results of the diagnosis. The complete model of the pneumatic drive was developed in the course 
of the study and from it a C++ source and a SCL source were generated. The C++ source was prepared as an 
executable DLL. The SCL source was prepared in STEP 7 and executed on a SIMATIC S7-300 and in S7-PLCSIM. 
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Figure 3: Diagnosis module in CFC 



6. Testing environment 

In the last step a simple run environment that simulates the machine run is set up. The diagnostic modules were 
interconnected with the virtual process present with them. 

7. Results and outlook 

The executed tests represent the basis for the wide-ranging investigation of the suitability for use of this technology. 
It was first determined that the diagnostic modules calculate the same results on SIMATIC-S7 and S7-PLCSIM as 
the diagnostic modules in the form of C++-DLLs running on PCs. 

The component approach shows the feasibility of a diagnostic standard module library that can cover a large 
percentage of automation solutions with a small reserve of types. This library can be organized hierarchically and 
contain base types (valve, motor, . . .) as well as multi-unit, component-oriented types (pneumatic drives, . . .). The 
diagnostic modules can be used potentially as technological functions or in the framework of diagnostic face plates. 
The usability of diagnostic modules on a SIMATIC S7 is limited due to the permissible maximum size of modules 
in downloading. With larger modules a division can in fact be performed that would however not be very efficient 
and would in addition violate the component-oriented approach. Furthermore, the load of the cycle with additional 
modules may not be disregarded. 

The technology of the model-based diagnosis represents for the engine object and WinAC an interesting 
enhancement. The load capacity of the procedure must be investigated in a real environment. In particular, the 
degree of coverage of necessary technological components by interconnectable diagnostic modules as well as 
conformity to the PCS7 library must be observed in any next step. In this connection the effort in developing a 
diagnostic standard module library is to be determined. 
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Automatic Generation of Diagnosis Programs for SPS-controlled 

Systems 

Problem: 

In the framework of process control systems great importance must be attached to diagnosis. On the one hand, a 
malfunction must be recognized within the shortest time so that damaging aftereffects can be prevented. On the 
other hand, the cause of the fault must be identified precisely so that the repair times, and consequently the 
t downtimes, are as short as possible. 

In order to be able to realize the objects of the diagnosis, knowledge of the process is needed. Previously, explicit 
diagnostic rules have frequently been formulated and applied in diagnostic systems, i.e. IF-THEN rules of the form 
"IF measured values THEN fault." In so doing, a major problem is systematic rule generation, especially in complex 
industrial systems. 

The knowledge of the process is frequently only incomplete and uncertain. It is necessary to use a correct formalism 
to register and handle this uncertainty. 

As a rule, the results of diagnosis are ambiguous because different faults can give rise to the same measurements. On 
account of this, a weighting of different faults is desirable. 

The effects of the faults are not always measurable at the time they occur but rather only make themselves 
noticeable at a later time. Such delays must be taken into account in the knowledge of the process as well as in the 
realization of the object of the diagnosis. 

An additional important criterion for the use of diagnosis systems is that they can be incorporated economically into 
existing hardware and software of process control technology. 

Solution: 

The essential features of the diagnosis developed are: 
1. Use of qualitative models: 

The models for the diagnosis can be formulated very roughly. Instead of the precise description of the relationships 
between the signals, logical model formulas, such as, for example, IF-THEN rules, are often adequate: 

IF causes THEN effects, 
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which are expressed here in the following notation: 
Values_of_the_input_signals => Values_of_the_output_signals 

These models necessary for diagnosis represent a very rough description of the normal or faulty process behavior 
and can be developed with relatively little effort. However, the direction of action described in the models (values of 
the input signals and the faults cause values of the output signals) do not correspond to the final direction of 
inference for the realization of the objects of diagnosis (values of the measurable signals lead to statements about 
faults). 



2. Extension to dynamic relationships: 

Using only static relationships is rarely sufficient since certain signal configurations only have as consequences 
effects at the next point in time. As the model forms, a clocked automaton was chosen which describes how the 
instantaneous values of the input signals and the instantaneous state cause the values of the output signals and the 
following instantaneous state. The current point in time is marked by k, the one following that by k + 1 : 

Values_of_the_input_signals(k) & state(k) => 
Values_of_the_output_signals(k) & state(k+l). 



3. Extension to fault models: 



An extension that occasions a slightly greater complexity in modeling is the use of fault models. In these model 
forms the faults are incorporated on the condition side, that is, the faulty behavior for different faults is incorporated 
into the model: 



Values_of_the_input_signals(k) & state(k) & fault(k) => 
Values_of_the_output_signals(k) & state(k+l). 

4. Extension to uncertain models: 



The causal relationships in the logical model can be enhanced by causally related probabilities. 

Values_of_the_input_signals(k) & state(k) & fault(k) => 
Values_of_the_output_signals(k) & state(k-H) 

/ P(V alues_of_the_output_signals(k) & state(k+ 1 ) 
Values_of_the_input_signals(k) & state(k) & fault(k)). 

In this way it can be expressed that certain outputs only occur with a certain frequency. 
5. Use of component libraries and hierarchies: 

As a rule, a system model is constructed with an orientation toward components. In so doing, a component can 
represent 
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♦ A control/regulation function that is intended to run on an automation device or 

• a physical, technological process component. 

These components are typed. An actual system is described by instances of these types (type-instance concept). 

Furthermore, components are structured hierarchically, that is, they can themselves be constructed from other 
components. 

Each component is described by an automaton expressed in notation in the form of logical formulas. 

The modeling for the diagnosis can frequently be accomplished with relative simple means. It can, for example, be 
done in parallel to the design of the control unit. 

6. Division of the diagnosis algorithm into off-line and on-line phases: 

The object of the diagnosis consists of detenriining, from the measured values, the faults occurring in the process: 
Diagnosis algorithm: 

Given: Measured value sequences, 
Model, 



Sought: Fault 



Measured value Fault 

t 




Diagnosis 



Figure 1 Fundamental schema of the diagnosis 

This objective can be realized with various methods. However, the realization of this object can frequently be time- 
critical so that the computational steps taking place at the time of diagnosis must be optimized. On account of this 
there is a division of the diagnosis algorithm into an off-line and on-line phase. In the off-line phase a diagnosis 
program is generated from the process model, where the diagnosis program enables the inference, from the 
measured values, of faults under real-time conditions in the on-line phase. 

In the on-line phase the diagnosis program is generated from the system model and corresponding specifications for 
the hardware and software environment of the on-line phase. 

Diagnosis algorithm: 



Given: 



Model, 

Specifications for the hardware and software environment 



Sought: Diagnosis program 
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Figure 2 Subdivision of the diagnosis into on-line and off-line phases 
This diagnosis program then executes the diagnosis in the system environment (on-line phase): 
On-line phase: 

Given: Measured values, 
Diagnosis program, 

Sought: Faults 

The off-line phase is realized with the logical programming language Prolog. The diagnosis program is formed 
according to the specifications in the syntax of an imperative programming language. At present programs can be 
generated in SCL and C++. 

7. Calculation of the probability of faults occurring: 

Instead of the output of four alternative solutions that consist of combinations of faults, there is a calculation of the 
probabilities of occurrence. 

The solution consists of the associated probability for each fault that it occurred under the condition of the 
measurements that occurred previously (0 . . . k): 



P(fault(k) I Values_ofjhe__output_signals(0 . . . k) & 

Values_of_the_input_signals(0 . . . k)). 

As an intermediate result the calculation of 



P(fault(k) & state(k+l) | Values_of_the_output_signals(0 . . . k) & 

Values_of_the_input_signals(0 . . . k)). 

is necessary for this and done recursively. 

8. Calculation of the probability of faults occurring in the past: 
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Corresponding to process dynamics, faults often do not have an effect at the moment of their occurrence but rather 
only after a certain time and then can only be recognized based on the measurements. On account of this, it is 
calculated for each fault with what probability it occurred sometime in the past: 



P(fault(k) v fault(k-l) v . . . v fault(0) 
Values_of_the_output_signals(0 . . . k) & Values_of_the_input_signals(0 . . . k)). 

As an intermediate result the calculation of 

P(-fault(k) & ... & -fault(O) & state(k+l) 

Values_of_the_output_signals(0 . . . k) & Values_of_the_input_signals(0 . . . k) & 
-fault(k) & ... & -fault(O)). 

is necessary for this and done recursively. 

9. Calculation of the probability of a composite fault: 



As a summary of the probabilities of occurrence of faults the probability of a composite fault is calculated, that is, 
the probability that any fault occurs. Only when this probability assumes the value 1 must the probabilities of the 
individual faults be considered in more detail. 
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1. Einleitung 

Fur die Betreiber der immer komplexer werdenden Maschinen und Anlagen ist die Erzielung eines 
effizienten Betripbs (techn. Verfugbarkeit, Ausbringung, ...) von entscheidender Bedeutung. Es sind 
hlerzu Strategies erforderlich, die es gestatten, im Stdrungsfall schnell und wirkungsvoll einzugreifen. 
Der Anlagen-Diagnose kommt hier eine besondere Bedeutung zu. 

Im Rahmen einer Vorfeld-Studie wurde ein Demonstrator fur die Modellbasierte Diagnose (MBD) 
entwickelt. Es wurden hierfur Diagnosemethoden, die bei ZT SE4 entwickelt wurden, herangezogen. 
Mittels dieser Methoden wurde eine reale Maschinenkomponente modelliert und darauf aufbauend 
Diagnoseaufgaben geldst. 

Ziel der Untersuchung war es, die technische Machbarkeit der Vorgehensweise nachzuweisen und 
herauszuf inden, welche potentiellen Plattformen fur den Einsatz dieser Technik herangezogen werden 
k6nnen. Ein wesentlicher Bestandteil war aufzuzeigen, da3 der Anwender die Modellbasierte 
Diagnose nicht programmieren muB, sondern die bendtigten Bausteine uber die zu messenden 
Signale mit dem ProzeB verschaltet. 

2. Demonstrationsbeispiel 

Das fur diese Aufgabe gewShlte Beispiel ist ein Ausschnitt aus einer Fertigungslinie. Es handelt sich 
dabei um die Komponente Auffangbehalter einer Schraubstation bei AT ER. Diese Komponente hat 
die Aufgabe, eine Mechanik mittels pneumatischer Antriebe von einer Grundstellung in eine 
Arbeitsstellung und zurGck zu verfahren. 
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Bild 1 : Pneumatischer Antrieb 

Der Auffangbehalter ist eine Sicherheitsvorrichtung beim automatischen Verschrauben. Er besteht aus 
zwei pneumatischen Antrieben gemaB Bild 1. Ein solcher pneumatischer Antrieb wird Ober das 
Magnetventil angestoBen. Das Wegeventil schaltet und laBt die Druckluft in die iinke Kammer des 
Zylinders stromen, der darauf hin ausf ahrt. 



3. Steuerungsbausteine 

Derartige Komponenten werden ublicherweise durch Ablaufsteuerungen koordiniert Fur das Beispiel 
wurden einfache Steuerungsbausteine programmiert. Diese wurden zu einer Ablaufumgebung 
verschaltet, so daB die Diagnosebausteine angebunden und erprobt werden konnen. 

4. Modellbasierte Diagnose 

Die Modellbasierte Diagnose stellt Techniken bereft, die einen stetigen Soll-lst-Vergleich des 
Maschinenablaufs durchfQhren und hier die Fehlerwahrscheinlichkeiten der im Model! integrierten 
Komponenten berechnen. DafQr wurden explizite ProzeBmodelle verwendet, die eine Beschreibung 
des ProzeBverhaltens beinhalten. ( 
Die ProzeBmodelle bestehen aus Komponenten, die wiederum typisiert sind. Eine konkrete Anlage 
wird durch I nstanzen dieser Typen beschrieben. So Ist es beispielsweise mdglich, die Komponente 
Sensor einzufQhreni da sich sowohl der Sensor zum Erfassen der Grundstellung als auch der zum 
Erfassen der Arbeitsstellung gleich verhaiten. 

Nachfolgend wird das Beispiel (aus Bild 1) als Blockschaltbild dargestelit. Dort sind bereits die 
Komponenten mit den mdgllchen Fehlern marWert. 
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Biid 2: Blockschaltbild des Beispiels 



Fur jede Komponente muB ein Fehlermodell hinterlegt sein, das den Zusammenhang zwischen 
Eingangs- und AusgangsgroBen beschreibt: 
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gs_sensor 

Der Sensor liefert im ungestorten Betrieb (-gs_Sensor_defekt) eine 1 (gs^Sensor), wenn die 
Mechanik sich in der Grundstellung befindet (gs): 

gs & -gs_Sensor_defekt ==> gs_Sensor. 

Befindet sich die Mechanik auBerhalb der Grundstellung (-gs) oder tritt ein Sensordefekt 
(gs_Sensor_def ekt) auf f wird immer eine 0 geliefert (-gs_Sensor): 

-gs ==> -gs_Sensor. 
gs_Sensor_defekt ==> -gs_Sensor. 

Die Ausgabe des Sensor steht als MeBwert zur Verf Ogung. 

measurableSignals [gs_Sensor] . 

Mit der erreichten Granularitat der Modellierung liegt ein hinreichend genaues ProzeBmodell vor, urn 
Diagnoseaussagen bis in die Komponentenebene (Zylinder, Sensor, ...) treffen zu konnen ' Die 
eingesetzte Modellierungstechnik bietet die Moglichkeit, unterschiedliche Feinheitsgrade zu 
realisieren. Die Modelle besitzen eine Schnittstelle, uber die Aktor- und Sensorsignale erfaBt werden. 

5. Diagnosebausteine 

Aus dem konfigurierten PrpzeSmodell wird ein ablauffahiges Diagnoseprogramm (implementiert in 
C++ oder SCL) automatlsch generiert. 

Das Diagnoseprogramm Qbernimmt die diagnoseseitige Weiterschaltung der Soll-ProzeBschritte und 
die Berechnung der Diagnoseergebnisse. Es wurde im Rahmen der Studie das vollstandige Modell 
des pneumatischen Antriebs erstellt und daraus sowohl eine C++-Quelle als auch eine SCL-Quelle 
generiert. Die C++-Quelle wurde als ablauffShige DLL bereitgestellt. Die SCL-Quelle wurde in STEP 7 
bereitgestellt und sowohl auf einer SIMATIC S7-300 als auch in S7-PLCSIM zum Ablauf gebracht 
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Bild 3: Diagnosebaustein im CFC 



6. Erprobungsumgebung 

Im letzten Schritt wurde eine einfache Abiaufumgebung, die den Maschinenablauf sjmuliert, 
aufgebaut. Die Diagnosebausteine wurden mft dem damit vorliegenden virtuellen ProzeB verschaltet. 



7. Ergebnisse und Ausbtick 

Die durchgefuhrten Erprobungen stellen die Basis fur die weiterreichende Untersuchung der 
Einsatztauglichkeit dieser Technik dar. Es wurde zunachst festgestellt, daB die Diagnosebausteine auf 
SIMATIC-S7 und S7-PLCSIM dieselben Ergebnisse berechnen, wie die auf PC ablaufenden 
Diagnosemodule in Form von C++-DLLs. 

Der Komponentenansatz zeigt die Machbarkeit einer Diagnose-Standardbaustein-Bibliothek, die mit 
kleinem Typvorrat einengrpBen Anteii an Automatisierungslosungen abdecken kann. Diese Bibliothek 
kann hierarchisch gegliedert sein und sowohl Basistypen (Venti!, Motor, ...) ais auch aggregierte, 
komponentenorientierte Typen (pneumatischer Antrieb, -..) beinhalten. Die Diagnosemodule konnen 
potentiell ais technologlsche Funktionen oder im Rahmen von Diagnose-Faceplates zum Einsatz 
kommen. 

Die Einsetzbarkeit der Diagnosebausteine auf einer SIMATIC S7 1st begrenzt aufgrund der zulassigen 
MaximalgroBe von Bausteinen beim Runterladen. Bei groBeren Bausteinen kann zwar eine Aufteilung 
vorgenommen werden, die ware allerdings wenig effizient und wurde zudern djen 
komponentenorientierten Ansatz verletzen. Weiterhin darf die Belastung des Zyklusses bei 
zusatzlichen Bausteinen nicht vernachlassigt werden. 

Die Technik der Modeilbasierten Diagnose stellt fur die Object Engine und WinAC eine interessante 
Erganzung dar. Die Tragf&higkeit dieser Vorgehensweise muB in einer re^len Umgebung untersucht 
werden. Insbesondere der Abdeckungsgrad notwendiger technologischer Komponenten durch 
verschaltbare Diagnosebausteine sowie Konformitat zur PCS7-Bibliothek mpssen in einem nachslen 
Schritt betrachtet werden. In diesem Zusammenhang 1st der Erstellungsaufwand einer Diagnose- 
Standardbaustein-Bibliothek zu ermitteln. 
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Automatische Generierung von Diagnoseprogrammen fur 

SPS-gesteuerte Anlagen 



Problem: 

Im Rahmen von ProzeBleitsystemen kommt der Diagnose eine besondere Bedeutung zu 
Einerseits muli innerhalb kurzester Zeit ein Fehlverhalten erkannt werden damit Folge- 

!f h ^K.^ erhindert werden k6nnen ' andererseits muR die Fehlerursache genau 
iden WENNiziert werden, damit die Reparatur- und demzufolge die Stillstandszeiten 
moglichst kurz sind. 

Um Diagnoseaufgaben Ibsen zu konnen, wird Wissen Qber den ProzeB benetigt. Bisher 
werden in praktischen Diagnosesystemen haufig explizite Diagnoseregeln formuliert und 
angewendet, d.h. WENN-DANN-Regeln der Form „WENN MeBwerte DANN Fehler." Ein 
groBes Problem ist dabei eine systematische Regelgenerierung, speziell bei komplexen 
industriellen Anlagen. 

Das ProzeRwissen ist haufig nur unvollstandig oder unsicher bekannt. Es ist notwendig 
emen korrekten Formalismus zur Erfassung und Verarbeitung dieser Unsicherheit 
einzusetzen. 

Die Diagnoseergebnisse sind in der Regel mehrdeutig, weil verschiedene Fehler gleiche 
Messungen verursachen kennen. Erstrebenswert ist deswegen eine Wichtung verschiedener 
Fehler. 

Die Wirkungen der Fehler sind nicht immer zum Zeitpunkt ihres Auftretens meBbar, sondern 
machen sich erst mehrere Zeitpunkte spater bemerkbar. Solche VerzSgerungen mpssen 
sowohl im ProzeBwissen als auch bei der Losung der Diagnoseaufgabe berQcksichtiqt 
werden. 

Ein weiteres wichtiges Kriterium fQr den Einsatz von Diagnosesystemen ist, da& sie 
kqstengQnstig in bestehende Hard- und Software der Leittechnik eingebunden werden 
kQnnen. 



Losung: 

4 

Die wesentlichen Merkmale der entwickelten Diagnosemethode sind: 



1. Einsatz qualitativer Modelle: 

Die Modelle fQr die Diagnose konnen sehr grab formuliert werden. Anstelle der genauen 
Beschreibung der Beziehungen zwischen den Signalen reichen oft logische Modellformeln 
wie zum Beispiel WENN-DANN-Regeln: 

WENN Ursachen DANN Wirkungen, 
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die hier in folgender Form notiert werden: 

Werte_der_Eingangssignale ==> Werte_der_Ausgangssignale. 

Diese zur Diagnose notwendigen Modelle stellen eine sehr grobe Beschreibung des 
normalen bzw. fehlerhaften ProzelSverhaltens dar und sind mit relativ geringem Aufwand zu 
erstellen. Die in den Modellen beschriebene Wirkungsrichtung (Werte der Eingangssignale 
und der Fehler verursachen Werte der Ausgangssignale) entspricht jedoch nicht der 
ietztendlichen SchluSfolgerungsrichtung zur Losung von Diagnoseaufgaben (Werte der 
melibaren Signale fQhren auf Aussagen Qber Fehler). 



2. Erweiterung auf dynamische Beziehungen: 

Es reicht selten aus, ausschlieBlich statische Beziehungen zu verwenden, da bestimmte 
Signalbelegungen erst Wirkungen zum nSchsten Zeitpunkt zur Folge haben. Als Modellform 
wurde ein getakteter Automat gewShlt, der beschreibt, wie die momentanen Werte der 
Eingangssignale und der momentane Zustand die momentanen Werte der Ausgangssignale 
und den Folgezustand bewirken. Der aktuelle Zeitpunkt wird mit k markiert, der 
darauffolgende mit k+1 : 

Werte_der_Eingangssignale (k) & Zustand (k) ==> 
Werte_der_Ausgangssignale (k) & Zustand (k+l) . 

3. Erweiterung auf Fehlermodelle: 

Eine Erweiterung, die einen geringfilgig hoheren Modellierungsaufwand verursacht, ist die 
Verwendung von Fehlermodellen. In die Modellformeln werden auf der Bedingungsseite die 
Fehler mit aufgenommen, d.h., es werden die Fehlerverhalten bei verschiedenen Fehlern mit 
in das Modell aufgenommen: 

Werte_der^Eingangssignale(k) & Zustand (k) & Fehler (k) ==> 
Werte_der__Ausgangs signale (k) & Zustand (k+l) . 



4. Erweiterung auf unsichere Modelle: 

Die kausalen Beziehungen im logischen Modell kOnnen urn kausal bedingte 
Wahrscheinlichkeiten erganzt werden. 

Wert e_der_Eingangs signale (k) & Zustand (k) & Fehler (k) ==> 
Werte_der_Ausgangssignale(k) & Zustand (k+l) 

/ P(Werte_der_Ausgangssignale (k) & Zustand(k+1) | 
Werte_der_Eingangssignale(k) & Zustand (k) & Fehler(k)). 

Dadurch kann ausgedrQckt werden, daft bestimmte Ausgaben nur mit einer gewissen 
HSufigkeit auftreten. , 



5. Verwendung yon Komponentenbibliotheken und -hierarchien: 

Ein Anlagenmodell ist in der Regel komponentenorientiert aufgebaut. Eine Komponente kann 
dabei reprSsentieren 
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• eine Steuerungs-/Regelungsfunktion, die auf einem AutomatisierungsgerSt ablaufen soli 
oder ' 

• eine physikalische, technologische ProzeRkomponente. 

Diese Komponenten sind typisiert, eine konkrete Anlage wird durch Instanzen dieser TvDen 
beschrieben (Typ-lnstanz-Konzept). 

Weiterhin sind Komponenten hierarchisch strukturiert, d.h. sie kdnnen selbst wieder aus 
Komponenten aufgebaut sein. 

Jede Komponente wird durch einen in Form logischer Formeln notierten Automaten 
beschrieben. 

Die Modellierung fur die Diagnose ist hSufig mit relativ einfachen Mitteln zu bewerkstelligen 
Sie kann z.B. parallel zum Steuerungsentwurf erfolgen. 

6. Teilung des Diagnosealgorithmus in Off- und On-line-Phase: 

Die Aufgabe der Diagnose besteht darin, aus den MeBwerten die im ProzeB aufgetretenen 
Fehler zu ermitteln: 

Diagnosealgorithmus: 

Gegeben: MelSwertfolgen, 

Modell, 

Gesucht: Fehler 



MeGwerte Fehler - 

▲ 





, 2 






Modell 




Diagnose 


— — » 



Abbildung 1 Grundschema der Diagnose 



Diese Aufgabe kann mit verschiedenen Methoden geldst werden. Haufig ist die Losung 
dieser Aufgabe jedoch zeitkritisch, so daB die zum Diagnosezeitpunkt stattfindenden Be- 
rechnungsschritte optimiert werden mQssen. Deswegen erfolgt eine Teilung des 
Diagnosalgorithmus in eine Off-line- und eine On-line-Phase. In der Off-line-Phase wird aus 
dem ProzelSmodell ein Diagnoseprogramm erzeugt, das unter Echtzeitbedingungen in der 
On-line-Phase aus den MeBwerten das Schlulifolgern auf Fehler ermfiglicht. 

In der On-line-Phase wird aus dem Anlagenmodell und entsprechenden Vorgaben fQr die 
Hard- und Software-Umgebung der On-line-Phase das Diagnoseprogramm generiert: 

Off-line-Phase: 
Gegeben: Modell, 

» 

Vorgaben fQr die Hardware- und Software-Umgebung, 
Gesucht: Diagnoseprogramm 
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Vorgaben 



Diagnose- 
programm 



MeGwerte Fehler 

A 



On-line- 
Phase 



Abbildung 2 Unterteilung der Diagnose in On- und Off-line-Phase 



Dieses Diagnoseprogramm fuhrt dann die Diagnose in der Anlagenumgebung aus (On-line- 
Phase): 

On-line-Phase: 
Gegeben: Meftwerte, 

Diagnoseprogramm, 
Gesucht: Fehler 

Die Off-line-Phase ist mit der logischen Programmiersprache Prolog realisiert. Das 
Diagnoseprogramm wird entsprechend der Vorgaben in der Syntax einer imperativen 
Programmiersprache gebildet Zur Zeit sind Programme in SCL und C++ erzeugbar. 

7. Berechnung von Auftretenswahrscheinlichkeiten von Fehlern: 

Anstelle der Ausgabe vieler alternativen L6sungen ( die aus Kombinationen von Fehlern 
bestehen, findet die Berechnung von Auftretenswahrscheinlichkeiten statt 

Die Losung besteht in der bedingten Wahrscheinlichkeit fQr jeden Fehler, dall er unter der 
Bedingung der bisher aufgetretenen Messungen (o..k) auftrat: 

P (Fehler (k) | Wetrte_der_Ausgangssignale (0 . .k) £ 

Werte_der_Eingangssignale (0 . .k) ) . 

Als Zwischenergebnis ist dafQr die Berechnung von 

P (Fehler (k) & Zustand(k+1) | Werte_der_Ausgarigssignale (0 . .k) & 

Werte_der_Eingangssignale(0. .k)) . 

notwendig, die rekursiv erfolgt. 

8. Berechnung der Auftretenswahrscheinlichkeit von Fehlern in der Vergangenheit: 
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Entsprechend der Proze&dynamik wirken sich Fehler oft nicht im Moment ihres Auftretens 
sondern erst nach einer bestimmten Zeit aus, und sind dann erst aufgrund der Messungen 
-erkennbar. Deswegen wird fOr jeden Fehler berechnet, mit welcher Wahrscheinlichkeit er 
irgendwann in der Vergangenheit auftrat: 

P(Fehler(k) v Fehler (k-1) v ... v Fehler(0)| 

Werte_der_Ausgangs«?ignale ( 0 . . k) & Werte_der_Eingangssignale (0 . . k) } . 

Als Zwischenergebnis ist dafQr die Berechnung von 

P(-Fehler(k) & & -Fehler(O) & Zustand(k+1) | 

Werte_der_Ausgangssignale ( 0 . . k) & Werte_der_Eingangssignale ( 0 . . k) & 
-Fehler (k-l) & ... & -Fehler (0)). 

notwendig, die rekursiv erfolgt. 

9. Berechnung der Auftretenswahrscheinlichkeitdes Sammelfehlers: 

Als eine Zusammenfassung der Auftretenswahrscheinlichkeiten der Fehler wird die 
Wahrscheinlichkeit des Sammelfehlers berechnet, d.h. die Wahrscheinlichkeit, daB irgendein 
Fehler auftrat. Erst wenn diese Wahrscheinlichkeit den Wert 1 annimmt, mussen die 
Wahrscheinlichkeiten der einzelnen Fehler nSher betrachtet werden. 
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